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Abstract 


This document clarifies and updates the DNS-Based Authentication of 
Named Entities (DANE) TLSA specification (RFC 6698), based on 


subsequent implementation experience. It also contains guidance for 
implementers, operators, and protocol developers who want to use DANE 
records. 
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1. Introduction 


The DNS-Based Authentication of Named Entities (DANE) specification 
[RFC6698] introduces the DNS "TLSA" resource record (RR) type ("TLSA" 
is not an acronym). TLSA records associate a certificate or a public 
key of an end-entity or a trusted issuing authority with the 
corresponding Transport Layer Security (TLS) [RFC5246] or Datagram 
Transport Layer Security (DTLS) [RFC6347] transport endpoint. DANE 
relies on the DNS Security Extensions (DNSSEC) [RFC4033]. DANE TLSA 
records validated by DNSSEC can be used to augment or replace the use 
of trusted public Certification Authorities (CAs). 


The TLS and DTLS protocols provide secured TCP and UDP communication, 
respectively, over IP. In the context of this document, channel 
security is assumed to be provided by TLS or DTLS. By convention, 
"TLS" will be used throughout this document; unless otherwise 
specified, the text applies equally well to DTLS over UDP. Used 
without authentication, TLS provides protection only against 
eavesdropping through its use of encryption. With authentication, 
TLS also protects the transport against man-in-the-middle (MITM) 
attacks. 


[RFC6698] defines three TLSA record fields: the first with four 
possible values, the second with two, and the third with three. 
These yield 24 distinct combinations of TLSA record types. This 
document recommends a smaller set of best-practice combinations of 
these fields to simplify protocol design, implementation, and 
deployment. 


This document explains and recommends DANE-specific strategies to 
simplify "virtual hosting", where a single Service Provider transport 


endpoint simultaneously supports multiple hosted Customer Domains. 


Other related documents that build on [RFC6698] are [RFC7673] and 
[RFC7672]. 


Section 12 summarizes the normative updates this document makes to 
[RFC6698]. 


Dukhovni & Hardaker Standards Track [Page 3] 


REC 7671 DANE Operations October 2015 


1.1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


The following terms are used throughout this document: 


Web PKI: The Public Key Infrastructure (PKI) model employed by 
browsers to authenticate web servers. This employs a set of 
trusted public CAs to vouch for the authenticity of public keys 
associated with a particular party (the subject). 


Service Provider: A company or organization that offers to host a 
service on behalf of the owner of a Customer Domain. The original 
domain name associated with the service often remains under the 
control of the customer. Connecting applications may be directed 
to the Service Provider via a redirection RR. Example redirection 
records include MX, SRV, and CNAME. The Service Provider 
frequently provides services for many customers and needs to 
ensure that the TLS credentials presented to connecting 
applications authenticate it as a valid server for the requested 
domain. 


Customer Domain: As described above, a TLS client may be interacting 
with a service that is hosted by a third party. This document 
refers to the domain name used to locate the service (prior to any 
redirection) as the "Customer Domain". 


TLSA Publisher: The entity responsible for publishing a TLSA record 
within a DNS zone. This zone will be assumed DNSSEC-signed and 
validatable to a trust anchor (TA), unless otherwise specified. 
If the Customer Domain is not outsourcing its DNS service, the 
TLSA Publisher will be the customer itself. Otherwise, the TLSA 
Publisher may be the operator of the outsourced DNS service. 


Public key: The term "public key" is shorthand for the 
subjectPublicKeyInfo component of a PKIX [RFC5280] certificate. 


SNI: The Server Name Indication (SNI) TLS protocol extension allows 
a TLS client to request a connection to a particular service name 
of a TLS server ([RFC6066], Section 3). Without this TLS 


extension, a TLS server has no choice but to offer a certificate 
with a default list of server names, making it difficult to host 
multiple Customer Domains at the same IP-address-based TLS service 
endpoint (i.e., provide "secure virtual hosting"). 


Dukhovni & Hardaker Standards Track [Page 4] 


REC 7671 DANE Operations October 2015 


2a 


TLSA parameters: In [RFC6698], the TLSA record is defined to consist 
of four fields. The first three of these are numeric parameters 
that specify the meaning of the data in the fourth and final 
field. This document refers to the first three fields as "TLSA 
parameters", or sometimes just "parameters" when obvious from 
context. 


TLSA base domain: Per Section 3 of [RFC6698], TLSA records are 
stored at a DNS domain name that is a combination of a port and 
protocol prefix and a "base domain". In [RFC6698], the "base 
domain" is the fully qualified domain name of the TLS server. 
This document modifies the TLSA record lookup strategy to prefer 
the fully CNAME-expanded name of the TLS server, provided that 
expansion is "secure" (DNSSEC validated) at each stage of the 
expansion, and TLSA records are published for this fully expanded 
name. Thus, the "TLSA base domain" is either the fully 
CNAME-expanded TLS server name or otherwise the initial fully 
qualified TLS server name, whichever is used in combination with a 
port and protocol prefix to obtain the TLSA RRset. 


DANE TLSA Record Overview 


DANE TLSA [RFC6698] specifies a protocol for publishing TLS server 
certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035]. 
DANE TLSA records consist of four fields. The record type is 
determined by the values of the first three fields, which this 
document refers to as the "TLSA parameters" to distinguish them from 
the fourth and last field. The numeric values of these parameters 
were given symbolic names in [RFC7218]. The four fields are as 
follows: 


The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies 
four values: PKIX-TA(0), PKIX-EE (1), DANE-TA(2), and DANE—EE (3). 
There is an additional private-use value: PrivCert (255), which, 
given its private scope, shall not be considered further in this 
document. All other values are reserved for use by future 
specifications. 


The Selector field: Section 2.1.2 of [RFC6698] specifies two values: 


Cert (0) and SPKI (1). There is an additional private-use value: 
PrivSel(255). All other values are reserved for use by future 
specifications. 


The Matching Type field: Section 2.1.3 of [RFC6698] specifies three 
values: Full(0), SHA2-256(1), and SHA2-512(2). There is an 
additional private-use value: PrivMatch(255). All other values 
are reserved for use by future specifications. 
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The Certificate Association Data field: See Section 2.1.4 of 
[RFC6698]. This field stores the full value or digest of the 
certificate or subject public key as determined by the matching 
type and selector, respectively. 


In the Matching Type field, of the two digest algorithms -- 
SHA2-256 (1) and SHA2-512(2) -- as of the time of this writing, only 
SHA2-256(1) is mandatory to implement. Clients SHOULD implement 
SHA2-512 (2), but servers SHOULD NOT exclusively publish SHA2-512 (2) 
digests. The digest algorithm agility protocol defined in Section 9 
SHOULD be used by clients to decide how to process TLSA RRsets that 
employ multiple digest algorithms. Server operators MUST publish 
TLSA RRsets that are compatible (see Section 8) with digest algorithm 
agility (Section 9). 


Example TLSA Record 


In the example TLSA record below, the TLSA certificate usage is 
DANE-TA(2), the selector is Cert (0), and the matching type is 
SHA2-256(1). The last field is the Certificate Association Data 
field, which in this case contains the SHA2-256 digest of the server 
certificate. 


_25._tcp.mail.example.com. IN TLSA 2 0 1 ( 
E8B54E0B4BAA815B06D3462D65FBC7C0 
CF556ECCF9F5303EBFBB77D022F834C0 ) 


DANE TLS Requirements 


[RFC6698] does not discuss what versions of TLS are required when 
using DANE records. This document specifies that TLS clients that 
support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support 
TLS 1.2 or later. 


TLS clients using DANE MUST support the SNI extension of TLS 
[RFC6066]. Servers MAY support SNI and respond with a matching 
certificate chain but MAY also ignore SNI and respond with a default 
certificate chain. When a server supports SNI but is not configured 
with a certificate chain that exactly matches the client's SNI 
extension, the server SHOULD respond with another certificate chain 
(a default or closest match). This is because clients might support 
more than one server name but can only put a single name in the SNI 
extension. 
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4. DANE Certificate Usage Selection Guidelines 


As mentioned in Section 2, the TLSA Certificate Usage field takes one 
of four possible values. With PKIX-TA(0) and PKIX-EE (1), the 
validation of peer certificate chains requires additional 
preconfigured CA TAs that are mutually trusted by the operators of 
the TLS server and client. With DANE-TA(2) and DANE-EE (3), no 
preconfigured CA TAs are required and the published DANE TLSA records 
are sufficient to verify the peer’s certificate chain. 


Standards for application protocols that employ DANE TLSA can specify 


more specific guidance than [RFC6698] or this document. Such 
application-specific standards need to carefully consider which set 
of DANE certificate usages to support. Simultaneous support for all 


four usages is NOT RECOMMENDED for DANE clients. When all four 
usages are supported, an attacker capable of compromising the 
integrity of DNSSEC needs only to replace the server’s TLSA RRset 
with one that lists suitable DANE-EE (3) or DANE-TA(2) records, 
effectively bypassing any added verification via public CAs. In 
other words, when all four usages are supported, PKIX-TA(0) and 
PKIX-EE(1) offer only illusory incremental security over DANE-TA (2) 
and DANE-EE (3). 


Designs in which clients support just the DANE-TA(2) and DANE-EE (3) 
certificate usages are RECOMMENDED. With DANE-TA(2) and DANE-EE(3), 
clients don’t need to track a large changing list of X.509 TAs in 
order to successfully authenticate servers whose certificates are 
issued by a CA that is brand new or not widely trusted. 


The DNSSEC TLSA records for servers MAY include both sets of usages 
if the server needs to support a mixture of clients, some supporting 
one pair of usages and some the other. 


4.1. Opportunistic Security and PKIX Usages 


When the client’s protocol design is based on "Opportunistic 
Security" (OS) [RFC7435] and the use of authentication is based on 
the presence of server TLSA records, it is especially important to 
avoid the PKIX-EE(1) and PKIX-TA(0) certificate usages. 


When authenticated TLS is used opportunistically based on the 
presence of DANE TLSA records and no secure TLSA records are present, 
unauthenticated TLS is used if possible, and if TLS is not possible, 
perhaps even cleartext. However, if usable secure TLSA records are 
published, then authentication MUST succeed. Also, outside the 
browser space, there is no preordained canon of trusted CAs, and in 
any case there is no security advantage in using PKIX-TA(0) or 
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PKIX-EE(1) when the DANE-TA(2) and DANE-EE (3) usages are also 
supported (as an attacker who can compromise DNS can replace the 
former with the latter). 


Authentication via the PKIX-TA(0) and PKIX-EE (1) certificate usages 
is more brittle; the client and server need to happen to agree on a 
mutually trusted CA, but with OS the client is just trying to protect 
the communication channel at the request of the server and would 
otherwise be willing to use cleartext or unauthenticated TLS. The 
use of fragile mechanisms (like public CA authentication for some 
unspecified set of trusted CAs) is not sufficiently reliable for an 
OS client to honor the server’s request for authentication. OS needs 
to be non-intrusive and to require few, if any, workarounds for valid 
but mismatched peers. 


Because the PKIX-TA(0) and PKIX-EE(1) usages offer no more security 
and are more prone to failure, they are a poor fit for OS and 
SHOULD NOT be used in that context. 


4.2. Interaction with Certificate Transparency 


Certificate Transparency (CT) [RFC6962] defines an experimental 
approach that could be used to mitigate the risk of rogue or 
compromised public CAs issuing unauthorized certificates. This 
section clarifies the interaction of the experimental CT and DANE. 
This section may need to be revised in light of any future Standards 
Track version of CT. 


When a server is authenticated via a DANE TLSA RR with TLSA 
certificate usage DANE-EE (3), the domain owner has directly specified 
the certificate associated with the given service without reference 
to any public CA. Therefore, when a TLS client authenticates the TLS 
server via a TLSA record with usage DANE-EE(3), CT checks SHOULD NOT 
be performed. Publication of the server certificate or public key 
(digest) in a TLSA record in a DNSSEC-signed zone by the domain owner 
assures the TLS client that the certificate is not an unauthorized 
certificate issued by a rogue CA without the domain owner’s consent. 


When a server is authenticated via a DANE TLSA record with TLSA usage 
DANE-TA(2) and the server certificate does not chain to a known 
public root CA, CT cannot apply (CT logs only accept chains that 
start with a known public root). Since TLSA certificate usage 
DANE-TA(2) is generally intended to support non-public TAs, TLS 
clients SHOULD NOT perform CT checks with usage DANE-TA (2). 
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With certificate usages PKIX-TA(0) and PKIX-EE(1), CT applies just as 
it would without DANE. TLSA records of this type only constrain 
which CAs are acceptable in PKIX validation. All checks used in the 
absence of DANE still apply when validating certificate chains with 
DANE PKIX-TA(0) and PKIX-EE(1) constraints. 


4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE 


The choice of preferred certificate usages may need to change as an 
application protocol evolves. When transitioning between PKIX-TA/ 
PKIX-EE and DANE-TA/DANE-EE, clients begin to enable support for the 
new certificate usage values. If the new preferred certificate 
usages are PKIX-TA/EE, this requires installing and managing the 
appropriate set of CA TAs. During this time, servers will publish 
both types of TLSA records. At some later time, when the vast 
majority of servers have published the new preferred TLSA records, 
clients can stop supporting the legacy certificate usages. 
Similarly, servers can stop publishing legacy TLSA records once the 
vast majority of clients support the new certificate usages. 


5. Certificate-Usage-Specific DANE Updates and Guidelines 


The four certificate usage values from the TLSA record -- DANE-EE(3), 
DANE-TA(2), PKIX-EE(1), and PKIX-TA(0) -- are discussed below. 


5.1. Certificate Usage DANE-EE (3) 


In this section, the meaning of DANE-EE(3) is updated from [RFC6698] 
to specify that peer identity matching and validity period 
enforcement are based solely on the TLSA RRset properties. This 
document also extends [RFC6698] to cover the use of DANE 
authentication of raw public keys [RFC7250] via TLSA records with 
certificate usage DANE-EE (3) and selector SPKI (1). 


Authentication via certificate usage DANE-EE (3) TLSA records involves 
simply checking that the server's leaf certificate matches the TLSA 
record. In particular, the binding of the server public key to its 
name is based entirely on the TLSA record association. The server 
MUST be considered authenticated even if none of the names in the 
certificate match the client's reference identity for the server. 
This simplifies the operation of servers that host multiple Customer 
Domains, as a single certificate can be associated with multiple 
domains without having to match each of the corresponding reference 
identifiers. 
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; Multiple Customer Domains hosted by an example.net 

; Service Provider: 

i 

www.example.com. IN CNAME ex-com.example.net. 
www.example.org. IN CNAME ex-org.example.net. 


r 

; In the provider's DNS zone, a single certificate and TLSA 

; record support multiple Customer Domains, greatly simplifying 
"virtual hosting". 

r 

ex-com.example.net. IN A 192.0.2.1 

ex-org.example.net. IN A 192.0.2.1 

_443._tcp.ex-com.example.net. IN CNAME tlsa._dane.example.net. 

_443._tcp.ex-org.example.net. IN CNAME tlsa._dane.example.net. 

tlsa._dane.example.net. IN TLSA 3 1 1 e3b0c44298fc1c14... 


Also, with DANE-EE (3), the expiration date of the server certificate 
MUST be ignored. The validity period of the TLSA record key binding 
is determined by the validity period of the TLSA record DNSSEC 
signatures. Validity is reaffirmed on an ongoing basis by continuing 
to publish the TLSA record and signing the zone in which the record 
is contained, rather than via dates "set in stone" in the 
certificate. The expiration becomes a reminder to the administrator 
that it is likely time to rotate the key, but missing the date no 
longer causes an outage. When keys are rotated (for whatever 
reason), it is important to follow the procedures outlined in 
Section 8. 


If a server uses just DANE-EE(3) TLSA records and all its clients are 
DANE clients, the server need not employ SNI (i.e., it may ignore the 
client’s SNI message) even when the server is known via multiple 
domain names that would otherwise require separate certificates. It 
is instead sufficient for the TLSA RRsets for all the domain names in 
question to match the server’s default certificate. For application 
protocols where the server name is obtained indirectly via SRV 
records, MX records, or similar records, it is simplest to publish a 
single hostname as the target server name for all the hosted domains. 


In organizations where it is practical to make coordinated changes in 
DNS TLSA records before server key rotation, it is generally best to 
publish end-entity DANE-EE(3) certificate associations in preference 
to other choices of certificate usage. DANE-EE(3) TLSA records 
support multiple server names without SNI, don’t suddenly stop 
working when leaf or intermediate certificates expire, and don’t fail 
when a server operator neglects to include all the required issuer 
certificates in the server certificate chain. 
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More specifically, it is RECOMMENDED that at most sites TLSA records 
published for DANE servers be "DANE-EE (3) SPKI(1) SHA2-256(1)" 
records. Selector SPKI(1) is chosen because it is compatible with 
raw public keys [RFC7250] and the resulting TLSA record need not 
change across certificate renewals with the same key. Matching type 
SHA2-256(1) is chosen because all DANE implementations are required 
to support SHA2-256. This TLSA record type easily supports hosting 
arrangements with a single certificate matching all hosted domains. 
It is also the easiest to implement correctly in the client. 


Clients that support raw public keys can use DANE TLSA records with 
certificate usage DANE-EE (3) and selector SPKI(1) to authenticate 
servers that negotiate the use of raw public keys. Provided the 
server adheres to the requirements of Section 8, the fact that raw 
public keys are not compatible with any other TLSA record types will 
not get in the way of successful authentication. Clients that employ 
DANE to authenticate the peer server SHOULD NOT negotiate the use of 
raw public keys unless the server’s TLSA RRset includes "DANE-EE (3) 
SPKI(1)" TLSA records. 


While it is, in principle, also possible to authenticate raw public 
keys via "DANE-EE (3) Cert(0) Full(0)" records by extracting the 
public key from the certificate in DNS, extracting just the public 
key from a "3 0 0" TLSA record requires extra logic on clients that 
not all implementations are expected to provide. Servers that wish 
to support [RFC7250] raw public keys need to publish TLSA records 
with a certificate usage of DANE-EE (3) and a selector of SPKI (1). 


While DANE-EE(3) TLSA records are expected to be by far the most 
prevalent, as explained in Section 5.2, DANE-TA(2) records are a 
valid alternative for sites with many DANE services. Note, however, 
that virtual hosting is more complex with DANE-TA(2). Also, with 
DANE-TA(2), server operators MUST ensure that the server is 
configured with a sufficiently complete certificate chain and need to 
remember to replace certificates prior to their expiration dates. 


5.2. Certificate Usage DANE-TA(2) 


This section updates [RFC6698] by specifying a new operational 
requirement for servers publishing TLSA records with a usage of 
DANE-TA(2): such servers MUST include the TA certificate in their TLS 
server certificate message unless all such TLSA records are "2 0 0" 
records that publish the server certificate in full. 


Some domains may prefer to avoid the operational complexity of 
publishing unique TLSA RRs for each TLS service. If the domain 
employs a common issuing CA to create certificates for multiple TLS 
services, it may be simpler to publish the issuing authority as a TA 
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for the certificate chains of all relevant services. The TLSA query 
domain (TLSA base domain with port and protocol prefix labels) for 
each service issued by the same TA may then be set to a CNAME alias 
that points to a common TLSA RRset that matches the TA. For example: 


; Two servers, each with its own certificate, that share 

; a common issuer (TA). 

r 

wwwl.example.com. IN A 192.0.2.1 

www2.example.com. IN A 192.0.2.2 
_443._tcp.wwwl.example.com. IN CNAME tlsa._dane.example.com. 
_443._tcp.www2.example.com. IN CNAME tlsa._dane.example.com. 
tlsa._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14... 


The above configuration simplifies server key rotation, because while 
the servers continue to receive new certificates from a CA matched by 
the shared (target of the CNAMEs) TLSA record, server certificates 
can be updated without making any DNS changes. As the list of active 
issuing CAs changes, the shared TLSA record will be updated (much 
less frequently) by the administrators who manage the CAs. Those 
administrators still need to perform TLSA record updates with care, 
as described in Section 8. 


With usage DANE-TA(2), the server certificates will need to have 
names that match one of the client’s reference identifiers (see 
[RFC6125]). When hosting multiple unrelated Customer Domains (that 
can’t all appear in a single certificate), such a server SHOULD 
employ SNI to select the appropriate certificate to present to the 
client. 


5.2.1. Recommended Record Combinations 


TLSA records with a matching type of Full(0) are NOT RECOMMENDED. 
While these potentially obviate the need to transmit the TA 
certificate in the TLS server certificate message, client 
implementations may not be able to augment the server certificate 
chain with the data obtained from DNS, especially when the TLSA 
record supplies a bare key (selector SPKI(1)). Since the server will 
need to transmit the TA certificate in any case, server operators 
SHOULD publish TLSA records with a matching type other than Full(0) 
and avoid potential DNS interoperability issues with large TLSA 
records containing full certificates or keys (see Section 10.1.1). 
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TLSA Publishers employing DANE-TA(2) records SHOULD publish records 
with a selector of Cert(0). Such TLSA records are associated with 
the whole TA certificate, not just with the TA public key. In 
particular, when authenticating the peer certificate chain via such a 
TLSA record, the client SHOULD apply any relevant constraints from 
the TA certificate, such as, for example, path length constraints. 


While a selector of SPKI(1) may also be employed, the resulting TLSA 
record will not specify the full TA certificate content, and elements 
of the TA certificate other than the public key become mutable. This 
may, for example, enable a subsidiary CA to issue a chain that 
violates the TA's path length or name constraints. 


5.2.2. Trust Anchor Digests and Server Certificate Chain 
With DANE-TA(2), a complication arises when the TA certificate is 


omitted from the server's certificate chain, perhaps on the basis of 
Section 7.4.2 of [RFC5246]: 


The sender’s certificate MUST come first in the list. Each 
following certificate MUST directly certify the one preceding it. 
Because certificate validation requires that root keys be 
distributed independently, the self-signed certificate that 
specifies the root certificate authority MAY be omitted from the 
chain, under the assumption that the remote end must already 
possess it in order to validate it in any case. 


With TLSA certificate usage DANE-TA(2), there is no expectation that 
the client is preconfigured with the TA certificate. In fact, client 
implementations are free to ignore all locally configured TAs when 
processing usage DANE-TA(2) TLSA records and may rely exclusively on 
the certificates provided in the server’s certificate chain. But, 
with a digest in the TLSA record, the TLSA record contains neither 
the full TA certificate nor the full public key. If the TLS server’s 
certificate chain does not contain the TA certificate, DANE clients 
will be unable to authenticate the server. 


TLSA Publishers that publish TLSA certificate usage DANE-TA (2) 
associations with a selector of SPKI(1) or with a digest-based 
matching type (not Full(0)) MUST ensure that the corresponding server 
is configured to also include the TA certificate in its TLS handshake 
certificate chain, even if that certificate is a self-signed root CA 
and would have been optional in the context of the existing public 

CA PKI. 
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Only when the server TLSA record includes a "DANE-TA(2) Cert (0) 
Full(0)" TLSA record containing a full TA certificate is the TA 
certificate optional in the server's TLS certificate message. This 
is also the only type of DANE-TA(2) record for which the client MUST 
be able to verify the server's certificate chain even if the TA 
certificate appears only in DNS and is absent from the TLS handshake 
server certificate message. 


5.2.3. Trust Anchor Public Keys 
TLSA records with TLSA certificate usage DANE-TA(2), selector 
SPKI (1), and a matching type of Full(0) publish the full public key 
of a TA via DNS. In Section 6.1.1 of [RFC5280], the definition of a 
TA consists of the following four parts: 
1. the trusted issuer name, 
2. the trusted public key algorithm, 


3. the trusted public key, and 


4. optionally, the trusted public key parameters associated with the 
public key. 


Items 2-4 are precisely the contents of the subjectPublicKeyInfo 
published in the TLSA record. The issuer name is not included in the 
subjectPublicKeyInfo. 


With TLSA certificate usage DANE-TA(2), the client may not have the 
associated TA certificate and cannot generally verify whether or not 
a particular certificate chain is "issued by" the TA described in the 
TLSA record. 


When the server certificate chain includes a CA certificate whose 
public key matches the TLSA record, the client can match that CA as 
the intended issuer. Otherwise, the client can only check that the 
topmost certificate in the server's chain is "signed by" the TA's 
public key in the TLSA record. Such a check may be difficult to 
implement and cannot be expected to be supported by all clients. 


Thus, servers cannot rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA 
records to be sufficient to authenticate chains issued by the 
associated public key in the absence of a corresponding certificate 
in the server's TLS certificate message. Servers employing "2 1 0" 
TLSA records MUST include the corresponding TA certificate in their 
certificate chain. 
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If none of the server's certificate chain elements match a public key 
specified in a TLSA record, and at least one "DANE-TA(2) SPKI (1) 
Full(0)" TLSA record is available, it is RECOMMENDED that clients 
check to see whether or not the topmost certificate in the chain is 
signed by the provided public key and has not expired, and in that 
case consider the server authenticated, provided the rest of the 
chain passes validation, including leaf certificate name checks. 


5.3. Certificate Usage PKIX-EE (1) 


This certificate usage is similar to DANE-EE (3); but, in addition, 
PKIX verification is required. Therefore, name checks, certificate 
expiration, CT, etc. apply as they would without DANE. 


5.4. Certificate Usage PKIX-TA(0) 


This section updates [RFC6698] by specifying new client 
implementation requirements. Clients that trust intermediate 
certificates MUST be prepared to construct longer PKIX chains than 
would be required for PKIX alone. 


TLSA certificate usage PKIX-TA(0) allows a domain to publish 
constraints on the set of PKIX CAs trusted to issue certificates for 
its TLS servers. A PKIX-TA(0) TLSA record matches PKIX-verified 
trust chains that contain an issuer certificate (root or 
intermediate) that matches its Certificate Association Data field 
(typically a certificate or digest). 


PKIX-TA(0) requires more complex coordination (than with DANE-TA (2) 
or DANE-EE(3)) between the Customer Domain and the Service Provider 
in hosting arrangements. Thus, this certificate usage is 

NOT RECOMMENDED when the Service Provider is not also the TLSA 
Publisher (at the TLSA base domain obtained via CNAMEs, SRV records, 
or MX records). 


TLSA Publishers who publish TLSA records for a particular public root 
CA will expect that clients will only accept chains anchored at that 
root. It is possible, however, that the client’s trusted certificate 
store includes some intermediate CAs, either with or without the 
corresponding root CA. When a client constructs a trust chain 
leading from a trusted intermediate CA to the server leaf 
certificate, such a "truncated" chain might not contain the trusted 
root published in the server’s TLSA record. 


If the omitted root is also trusted, the client may erroneously 
reject the server chain if it fails to determine that the shorter 
chain it constructed extends to a longer trusted chain that matches 
the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record, 
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so long as no matching certificate has yet been found, a client MUST 
continue extending the chain even after any locally trusted 
certificate is found. If no TLSA records have matched any of the 
elements of the chain and the trusted certificate found is not 
self-issued, the client MUST attempt to build a longer chain in case 
a certificate closer to the root matches the server's TLSA record. 


6. Service Provider and TLSA Publisher Synchronization 


Whenever possible, the TLSA Publisher and the Service Provider should 
be the same entity. Otherwise, they need to coordinate changes to 
ensure that TLSA records published by the TLSA Publisher don't fall 
out of sync with the server certificate used by the Service Provider. 
Such coordination is difficult, and service outages will result when 
coordination fails. 


Publishing the TLSA record in the Service Provider's zone avoids the 
complexity of bilateral coordination of server certificate 
configuration and TLSA record management. Even when the TLSA RRset 
has to be published in the Customer Domain’s DNS zone (perhaps the 
client application does not "chase" CNAMEs to the TLSA base domain), 
it is possible to employ CNAME records to delegate the content of the 
TLSA RRset to a domain operated by the Service Provider. 


Only certificate usages DANE-EE (3) and DANE-TA(2) work well with TLSA 
CNAMEs across organizational boundaries. With PKIX-TA(0) or 
PKIX-EE(1), the Service Provider would need to obtain certificates in 
the name of the Customer Domain from a suitable public CA (securely 
impersonate the customer), or the customer would need to provision 
the relevant private keys and certificates at the Service Provider’s 
systems. 


Certificate Usage DANE-EE(3): In this case, the Service Provider can 
publish a single TLSA RRset that matches the server certificate or 
public key digest. The same RRset works for all Customer Domains 
because name checks do not apply with DANE-EE(3) TLSA records (see 
Section 5.1). A Customer Domain can create a CNAME record 
pointing to the TLSA RRset published by the Service Provider. 


Certificate Usage DANE-TA(2): When the Service Provider operates a 
private CA, the Service Provider is free to issue a certificate 
bearing any customer’s domain name. Without DANE, such a 
certificate would not pass trust verification, but with DANE, the 
customer’s TLSA RRset that is aliased to the provider’s TLSA RRset 
can delegate authority to the provider’s CA for the corresponding 
service. The Service Provider can generate appropriate 
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certificates for each customer and use the SNI information 


provided by clients to selec 
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whose clients all support DANE 
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( 


(see Section 7 below). 


The hosted web service is red 


t the right certificate chain to 


assumed "secure" and shown without the 
such as record signatures) that 

dels in the case of an HTTPS service 
TLS. These examples work even with 


"chase" CNAMEs when constructing the TLSA base 


irected via a CNAME alias. 


r 


The associated TLSA RRset is 


Certificate usage DANE-EE (3) 
a single provider certificate 


T 


wwwl.example.com. IN 
_443._tcp.wwwl.example.com. IN 
_443._tcp.wl.example.net. IN 


i 
A CA at the provider can also 
Domain and employ the DANE-TA 


r 


, 
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i 
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TLSA 3 1 1 ( 
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TLSA 201 ( 
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sport endpoint rather than the origin 
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domains for TLSA records that are published and managed by the 
Service Provider. For example (without the required DNSSEC 
information, such as record signatures): 


; Hosted SMTP service. 
example.com. IN MX 0 mx1.example.net. 
example.com. IN MX 0 mx2.example.net. 
25._tcp.mxl.example.net. IN TLSA 3 1 1 ( 
8A9A70596E869BED72C69D97A8895DFA 
D86F300A343FECEFF19E89C27C896BC9 ) 
_25._tcp.mx2.example.net. IN TLSA 3 1 1 ( 
C164B2C3F36D068D42A6138E446152F5 
68615F28C69BD96A73E354CAC88EDOO0C ) 


If redirection to the Service Provider's domain (via MX records, SRV 
records, or any similar mechanism) is not possible and aliasing of 
the TLSA record is not an option, then more complex coordination 
between the Customer Domain and Service Provider will be required. 
Either the Customer Domain periodically provides private keys and a 
corresponding certificate chain to the provider (after making 
appropriate changes in its TLSA records), or the Service Provider 
periodically generates the keys and certificates and needs to wait 
for matching TLSA records to be published by its Customer Domains 
before deploying newly generated keys and certificate chains. 
Section 7 below describes an approach that employs CNAME "chasing" to 
avoid the difficulties of coordinating key management across 
organizational boundaries. 


For further information about combining DANE and SRV, please see 
[RFC7673]. 


7. #TLSA Base Domain and CNAMEs 


When the application protocol does not support service location 
indirection via MX, SRV, or similar DNS records, the service may be 
redirected via a CNAME. A CNAME is a more blunt instrument for this 
purpose because, unlike an MX or SRV record, it remaps the entire 
origin domain to the target domain for all protocols. 


The complexity of coordinating key management is largely eliminated 
when DANE TLSA records are found in the Service Provider’s domain, as 
discussed in Section 6. Therefore, DANE TLS clients connecting to a 
server whose domain name is a CNAME alias SHOULD follow the CNAME 
"hop by hop" to its ultimate target host (noting at each step whether 
or not the CNAME is DNSSEC validated). If at each stage of CNAME 
expansion the DNSSEC validation status is "secure", the final target 
name SHOULD be the preferred base domain for TLSA lookups. 
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Implementations failing to find a TLSA record using a base name of 
the final target of a CNAME expansion SHOULD issue a TLSA query using 
the original destination name. That is, the preferred TLSA base 
domain SHOULD be derived from the fully expanded name and, failing 
that, SHOULD be the initial domain name. 


When the TLSA base domain is the result of "secure" CNAME expansion, 
the resulting domain name MUST be used as the HostName in the 
client’s SNI extension and MUST be the primary reference identifier 
for peer certificate matching with certificate usages other than 
DANE-—EE (3). 


Protocol-specific TLSA specifications may provide additional guidance 
or restrictions when following CNAME expansions. 


Though CNAMEs are illegal on the right-hand side of most indirection 
records, such as MX and SRV records, they are supported by some 
implementations. For example, if the MX or SRV host is a CNAME 
alias, some implementations may "chase" the CNAME. If they do, they 
SHOULD use the target hostname as the preferred TLSA base domain as 
described above (and, if the TLSA records are found there, also use 
the CNAME-expanded domain in SNI and certificate name checks). 


8. TLSA Publisher Requirements 


This section updates [RFC6698] by specifying that the TLSA Publisher 
MUST ensure that each combination of certificate usage, selector, and 
matching type in the server’s TLSA RRset includes at least one record 
that matches the server’s current certificate chain. TLSA records 
that match recently retired or yet-to-be-deployed certificate chains 
will be present during key rollover. Such past or future records 
MUST NOT at any time be the only records published for any given 
combination of usage, selector, and matching type. The TLSA record 
update process described below ensures that this requirement is met. 


While a server is to be considered authenticated when its certificate 
chain is matched by any of the published TLSA records, not all 


clients support all combinations of TLSA record parameters. Some 
clients may not support some digest algorithms; others may either not 
support or exclusively support the PKIX certificate usages. Some 


clients may prefer to negotiate [RFC7250] raw public keys, which are 
only compatible with TLSA records whose certificate usage is 
DANE-EE(3) with selector SPKI(1). The only other TLSA record type 
that is potentially compatible with raw public keys is "DANE-EE (3) 
Cert (0) Full(0)", but support for raw public keys with that TLSA 
record type is not expected to be broadly implemented. 
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A consequence of the above uncertainty as to which TLSA parameters 
are supported by any given client is that servers need to ensure that 
each and every parameter combination that appears in the TLSA RRset 
is, on its own, sufficient to match the server's current certificate 
chain. In particular, when deploying new keys or new parameter 
combinations, some care is required to not generate parameter 
combinations that only match past or future certificate chains (or 


raw public keys). The rest of this section explains how to update 
the TLSA RRset in a manner that ensures that the above requirement 
is met. 


8.1. Key Rollover with Fixed TLSA Parameters 


The simplest case is key rollover while retaining the same set of 
published parameter combinations. In this case, TLSA records 
matching the existing server certificate chain (or raw public keys) 
are first augmented with corresponding records matching the future 
keys, at least two Times to Live (TTLs) or longer before the new 
chain is deployed. This allows the obsolete RRset to age out of 
client caches before the new chain is used in TLS handshakes. Once 
sufficient time has elapsed and all clients performing DNS lookups 
are retrieving the updated TLSA records, the server administrator may 
deploy the new certificate chain, verify that it works, and then 
remove any obsolete records matching the chain that is no longer 
active: 


; Initial TLSA RRset. 
; 


_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 


; Transitional TLSA RRset published at least two TTLs before 
; the actual key change. 

r 

_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 


; Final TLSA RRset after the key change. 


A 


_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 
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The next case to consider is adding or switching to a new combination 
of TLSA parameters. In this case, publish the new parameter 
combinations for the server's existing certificate chain first, and 
only then deploy new keys if desired: 


; Initial TLSA RRset. 
; 


_443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46... 


; New TLSA RRset, same key re-published as DANE-EE (3). 
i 


_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 
8.2. Switching to DANE-TA(2) from DANE-EE (3) 


This section explains how to migrate to a new certificate chain and 
TLSA record with usage DANE-TA(2) from a self-signed server 
certificate and a "DANE-EE (3) SPKI(1) SHA2-256(1)" TLSA record. This 
example assumes that a new private key is generated in conjunction 
with transitioning to a new certificate issued by the desired TA. 


The original "3 1 1" TLSA record supports [RFC7250] raw public keys, 
and clients may choose to negotiate their use. The use of raw public 
keys rules out the possibility of certificate chain verification. 
Therefore, the transitional TLSA record for the planned DANE-TA (2) 
certificate chain is a "3 1 1" record that works even when raw public 
keys are used. The TLSA RRset is updated to use DANE-TA(2) only 
after the new chain is deployed and the "3 1 1" record matching the 
original key is dropped. 


This process follows the requirement that each combination of 
parameters present in the RRset is always sufficient to validate the 
server. It avoids publishing a transitional TLSA RRset in which 

"3 1 1" matches only the current key and "2 0 1" matches only the 
future certificate chain, because these might not work reliably 
during the initial deployment of the new keys. 
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; Initial TLSA RRset. 
; 


_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 


; Transitional TLSA RRset, published at least two TTLs before the 
; actual key change. The new keys are issued by a DANE-TA(2) CA 
; but are initially specified via a DANE-EE(3) association. 


_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 


; The final TLSA RRset after the key change. Now that the old 
; self-signed EE key is out of the picture, publish the issuing 
; TA of the new chain. 


_443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d... 
8.3. Switching to New TLSA Parameters 


When employing a new digest algorithm in the TLSA RRset, for 
compatibility with digest algorithm agility as specified in Section 9 
below, administrators SHOULD publish the new digest algorithm with 
each combination of certificate usage and selector for each 
associated key or chain used with any other digest algorithm. When 
removing an algorithm, remove it entirely. Each digest algorithm 
employed SHOULD match the same set of chains (or raw public keys). 


; Initial TLSA RRset with "DANE-EE (3) SHA2-256(1)" associations 
; for two keys. 

_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 


; New TLSA RRset, also with SHA2-512(2) associations 
; for each key. 


r 


_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... 
_443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc... 
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... 
_443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714... 


Dukhovni & Hardaker Standards Track [Page 22] 


REC 7671 DANE Operations October 2015 


8.4. TLSA Publisher Requirements: Summary 


In summary, server operators updating TLSA records should make one 
change at a time. The individual safe changes are as follows: 


o Pre-publish new certificate associations that employ the same TLSA 
parameters (usage, selector, and matching type) as existing TLSA 
records, but match certificate chains that will be deployed in the 
near future. 


o Wait for stale TLSA RRsets to expire from DNS caches before 
configuring servers to use the new certificate chain. 


o Remove TLSA records matching any certificate chains that are no 
longer deployed. 


o Publish TLSA RRsets in which all parameter combinations 
(certificate usage, selector, and matching type) present in the 
RRset match the same set of current and planned certificate 
chains. 


The above steps are intended to ensure that at all times, and for 
each combination of usage, selector, and matching type, at least one 
TLSA record corresponds to the server's current certificate chain. 
Each combination of certificate usage, selector, and matching type in 
a server's TLSA RRset SHOULD NOT at any time (including unexpired 
RRsets in client caches) match only some combination of future or 
past certificate chains. As a result, no matter what combinations of 
usage, selector, and matching type may be supported by a given 
client, they will be sufficient to authenticate the server. 


9. Digest Algorithm Agility 


While [RFC6698] specifies multiple digest algorithms, it does not 
specify a protocol by which the client and TLSA record publisher can 
agree on the strongest shared algorithm. Such a protocol would allow 
the client and server to avoid exposure to deprecated weaker 
algorithms that are published for compatibility with less capable 
clients but that SHOULD be avoided when possible. Such a protocol is 
specified below. 


This section defines a protocol for avoiding deprecated digest 
algorithms when these are published in a peer's TLSA RRset alongside 
stronger digest algorithms. Note that this protocol never avoids RRs 
with a DANE matching type of Full(0), as these do not employ a digest 
algorithm that might someday be weakened by cryptanalysis. 
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Client implementations SHOULD implement a default order of digest 
algorithms by strength. This order SHOULD be configurable by the 
administrator or user of the client software. If possible, a 
configurable mapping from numeric DANE TLSA matching types to 
underlying digest algorithms provided by the cryptographic library 
SHOULD be implemented to allow new matching types to be used with 
software that predates their introduction. Configurable ordering of 
digest algorithms SHOULD be extensible to any new digest algorithms. 


To make digest algorithm agility possible, all published DANE TLSA 
RRsets MUST conform to the requirements of Section 8. Clients SHOULD 
use digest algorithm agility when processing the peer’s DANE TLSA 
records. Algorithm agility is to be applied after first discarding 
any unusable or malformed records (unsupported digest algorithm, or 
incorrect digest length). For each usage and selector, the client 
SHOULD process only any usable records with a matching type of 
Full(0) and the usable records whose digest algorithm is considered 
by the client to be the strongest among usable records with the given 
usage and selector. 


Example: a client implements digest algorithm agility and prefers 
SHA2-512(2) over SHA2-256(1), while the server publishes an RRset 
that employs both digest algorithms as well as a Full(0) record. 


_25._tcp.mail.example.com. IN TLSA 3 1 1 ( 
3FE246A848798236DD2AB78D39F0651D 
6B6E7CA8E2984012EB0A2E1AC8A87B72 ) 

_25._tcp.mail.example.com. IN TLSA 3 1 2 ( 
D4F5AF015B46C5057B841C7E7BAB759C 
BF029526D29520C5BE6A32C67475439E 
54AB3A945D80C743347C9BD4DADC9D8D 
57FAB78EAA835362F3CA07CCC19A3214 ) 

_25._tcp.mail.example.com. IN TLSA 3 1 0 ( 
3059301306072A8648CE3D020106082A 
8648CE3D0301070342000471CB1F504F 
9E4B33971376C005445DACD33CD79A28 
81C3DED1981F18E7AAA76609DD0E4EF2 
8265C82703030AD60C5DBA6FB8A9397A 
COFCF06D424C885D484887 ) 


T 


In this case, the client SHOULD accept a server public key that 
matches either the "3 1 0" record or the "3 1 2" record, but it 
SHOULD NOT accept keys that match only the weaker "3 1 1" record. 
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10. 


10. 


10. 


10. 


General DANE Guidelines 


These guidelines provide guidance for using or designing protocols 
for DANE. 


1. DANE DNS Record Size Guidelines 


Selecting a combination of TLSA parameters to use requires Careful 
thought. One important consideration to take into account is the 
size of the resulting TLSA record after its parameters are selected. 


1.1. UDP and TCP Considerations 


Deployments SHOULD avoid TLSA record sizes that cause UDP 
fragmentation. 


Although DNS over TCP would provide the ability to more easily 
transfer larger DNS records between clients and servers, it is not 
universally deployed and is still prohibited by some firewalls. 
Clients that request DNS records via UDP typically only use TCP upon 
receipt of a truncated response in the DNS response message sent over 
UDP. Setting the Truncation (TC) bit (Section 4.1.1 of [RFC1035]) 
alone will be insufficient if the response containing the TC bit is 
itself fragmented. 


1.2. Packet Size Considerations for TLSA Parameters 


Server operators SHOULD NOT publish TLSA records using both a TLSA 
selector of Cert(0) and a TLSA matching type of Full(0), as even a 
single certificate is generally too large to be reliably delivered 
via DNS over UDP. Furthermore, two TLSA records containing full 
certificates will need to be published simultaneously during a 
certificate rollover, as discussed in Section 8.1. 


While TLSA records using a TLSA selector of SPKI(1) and a TLSA 
matching type of Full(0) (which publish the bare public keys, i.e., 
without the overhead of encapsulating the keys in an X.509 
certificate) are generally more compact, these are also best avoided 
when significantly larger than their digests. Rather, servers SHOULD 
publish digest-based TLSA matching types in their TLSA records, in 
which case the complete corresponding certificate MUST be transmitted 
to the client in-band during the TLS handshake. The certificate (or 
raw public key) can be easily verified using the digest value. 


In summary, the use of a TLSA matching type of Full(0) is 
NOT RECOMMENDED, and a digest-based matching type, such as 
SHA2-256(1), SHOULD be used instead. 
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10 


.2. Certificate Name Check Conventions 


Certificates presented by a TLS server will generally contain a 
subjectAltName (SAN) extension or a Common Name (CN) element within 
the subject Distinguished Name (DN). The TLS server's DNS domain 
name is normally published within these elements, ideally within the 
SAN extension. (The use of the CN field for this purpose is 
deprecated.) 


When a server hosts multiple domains at the same transport endpoint, 
the server's ability to respond with the right certificate chain is 

predicated on correct SNI information from the client. DANE clients 
MUST send the SNI extension with a HostName value of the base domain 
of the TLSA RRset. 


With the exception of TLSA certificate usage DANE-EE (3), where name 
checks are not applicable (see Section 5.1), DANE clients MUST verify 
that the client has reached the correct server by checking that the 
server name is listed in the server certificate's SAN or CN (when 
still supported). The primary server name used for this comparison 
MUST be the TLSA base domain; however, additional acceptable names 
may be specified by protocol-specific DANE standards. For example, 
with SMTP, both the destination domain name and the MX hostname are 
acceptable names to be found in the server certificate (see 
[RFC7672]). 


It is the responsibility of the service operator, in coordination 
with the TLSA Publisher, to ensure that at least one of the TLSA 
records published for the service will match the server’s certificate 
chain (either the default chain or the certificate that was selected 
based on the SNI information provided by the client). 


Given the DNSSEC-validated DNS records below: 


example.com. IN MX 0 mail.example.com. 

mail.example.com. IN A 192.0.2.1 

_25._tcp.mail.example.com. IN TLSA 2 0 1 ( 
E8B54E0B4BAA815B06D3462D65FBC7CO 
CF556ECCF 9F5303EBFBB77D022F834C0 ) 


The TLSA base domain is "mail.example.com" and is required to be the 
HostName in the client’s SNI extension. The server certificate chain 
is required to be signed by a TA with the above certificate SHA2-256 
digest. Finally, one of the DNS names in the server certificate is 
required to be either "mail.example.com" or "example.com" (this 
additional name is a concession to compatibility with prior practice; 
see [RFC7672] for details). 
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10. 


[RFC6125] specifies the semantics of wildcards in server certificates 
for various application protocols. DANE does not change how 
wildcards are treated by any given application. 


3. Design Considerations for Protocols Using DANE 


When a TLS client goes to the trouble of authenticating a certificate 
chain presented by a TLS server, it will typically not continue to 
use that server in the event of authentication failure, or else 
authentication serves no purpose. Some clients may, at times, 
operate in an "audit" mode, where authentication failure is reported 
to the user or in logs as a potential problem, but the connection 
proceeds despite the failure. Nevertheless, servers publishing TLSA 
records MUST be configured to allow correctly configured clients to 
successfully authenticate their TLS certificate chains. 


A service with DNSSEC-validated TLSA records implicitly promises TLS 
support. When all the TLSA records for a service are found 
"unusable" due to unsupported parameter combinations or malformed 
certificate association data, DANE clients cannot authenticate the 
service certificate chain. When authenticated TLS is mandatory, the 
client MUST NOT connect to the associated server. 


If, on the other hand, the use of TLS and DANE is "opportunistic" 
[RFC7435], then when all TLSA records are unusable, the client SHOULD 
connect to the server via an unauthenticated TLS connection, and if 
TLS encryption cannot be established, the client MUST NOT connect to 
the server. 


Standards for opportunistic DANE TLS specific to a particular 
application protocol may modify the above requirements. The key 
consideration is whether or not mandating the use of 
(unauthenticated) TLS even with unusable TLSA records is asking for 
more security than one can realistically expect. If expecting TLS 
support when unusable TLSA records are published is realistic for the 
application in question, then the application MUST avoid cleartext. 
If not realistic, then mandating TLS would cause clients (even in the 
absence of active attacks) to run into problems with various peers 
that do not interoperate "securely enough". That would create strong 
incentives to just disable Opportunistic Security and stick with 
cleartext. 
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11. Note on DNSSEC Security 


Clearly, the security of the DANE TLSA PKI rests on the security of 
the underlying DNSSEC infrastructure. While this document is not a 
guide to DNSSEC security, a few comments may be helpful to TLSA 
implementers. 


With the existing public CA Web PKI, name constraints are rarely 
used, and a public root CA can issue certificates for any domain of 
its choice. With DNSSEC, under the Registry/Registrar/Registrant 
model, the situation is different: only the registrar of record can 
update a domain's DS record [RFC4034] in the registry parent zone (in 
some cases, however, the registry is the sole registrar). With many 
Generic Top-Level Domains (gTLDs) for which multiple registrars 
compete to provide domains in a single registry, it is important to 
make sure that rogue registrars cannot easily initiate an 
unauthorized domain transfer and thus take over DNSSEC for the 
domain. DNS operators are advised to set a registrar lock on their 
domains to offer some protection against this possibility. 


When the registrar is also the DNS operator for the domain, one needs 
to consider whether or not the registrar will allow orderly migration 
of the domain to another registrar or DNS operator in a way that will 
maintain DNSSEC integrity. TLSA Publishers are advised to seek out a 
DNS hosting registrar that makes it possible to transfer domains to 
another hosting provider without disabling DNSSEC. 


DNSSEC-signed RRsets cannot be securely revoked before they expire. 
Operators need to plan accordingly and not generate signatures of 
excessively long duration. For domains publishing high-value keys, a 
signature lifetime (length of the "Signature validity period" as 
described in Section 8.1 of [RFC4033]) of a few days is reasonable, 
and the zone can be re-signed daily. For domains with less critical 
data, a reasonable signature lifetime is a couple of weeks to a 
month, and the zone can be re-signed weekly. 


Short signature lifetimes require tighter synchronization of primary 
and secondary nameservers, to make sure that secondary servers never 
serve records with expired signatures. They also limit the maximum 
time for which a primary server that signs the zone can be down. 
Therefore, short signature lifetimes are more appropriate for sites 
with dedicated operations staff, who can restore service quickly in 
case of a problem. 


Monitoring is important. If a DNS zone is not re-signed in a timely 


manner, a major outage is likely, as the entire domain and all its 
sub-domains become "bogus". 
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T2 


1.3% 


Summary of Updates to RFC 6698 


o Section 3 updates [RFC6698] to specify a requirement for clients 
to support at least TLS 1.0 and to support SNI. 


o Section 4 explains that application support for all four 
certificate usages is NOT RECOMMENDED. The recommended design is 
to support just DANE-EE(3) and DANE-TA(2). 


o Section 5.1 updates [RFC6698] to specify that peer identity 
matching and validity period enforcement are based solely on the 
TLSA RRset properties. It also specifies DANE authentication of 
raw public keys [RFC7250] via TLSA records with certificate usage 
DANE-EE (3) and selector SPKI(1). 


o Section 5.2 updates [RFC6698] to require that servers publishing 
digest TLSA records with a usage of DANE-TA(2) MUST include the 
TA certificate in their TLS server certificate message. This 
extends to the case of "2 1 0" TLSA records that publish a full 
public key. 


o Section 5.4 observes that with usage PKIX-TA(0), clients may need 
to process extended trust chains beyond the first trusted issuer 
when that issuer is not self-signed. 


o Section 7 recommends that DANE application protocols specify that, 
when possible, securely CNAME-expanded names be used to derive the 
TLSA base domain. 


o Section 8 specifies a strategy for managing TLSA records that 
interoperates with DANE clients regardless of what subset of the 
possible TLSA record types (combinations of TLSA parameters) is 
supported by the client. 


o Section 9 specifies a digest algorithm agility protocol. 


o Section 10.1 recommends against the use of Full(0) TLSA records, 
as digest records are generally much more compact. 


Operational Considerations 


The DNS TTL of TLSA records needs to be chosen with care. When an 
unplanned change in the server’s certificate chain and TLSA RRset is 
required, such as when keys are compromised or lost, clients that 
cache stale TLSA records will fail to validate the certificate chain 
of the updated server. Publish TLSA RRsets with TTLs that are short 
enough to limit unplanned service disruption to an acceptable 
duration. 
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The signature lifetime (length of the signature validity period) for 
TLSA records SHOULD NOT be too long. Signed DNSSEC records can be 
replayed by an MITM attacker, provided the signatures have not yet 
expired. Shorter signature validity periods allow for faster 
invalidation of compromised keys. Zone refresh and expiration times 
for secondary nameservers often imply a lower bound on the signature 
validity period (Section 11). See Section 4.4.1 of [RFC6781]. 


14. Security Considerations 


Application protocols that cannot use the existing public CA Web PKI 
may choose to not implement certain TLSA record types defined in 
[RFC6698]. If such records are published despite not being supported 
by the application protocol, they are treated as "unusable". When 
TLS is opportunistic, the client MAY proceed to use the server with 
mandatory unauthenticated TLS. This is stronger than opportunistic 
TLS without DANE, since in that case the client may also proceed with 
a cleartext connection. When TLS is not opportunistic, the client 
MUST NOT connect to the server. 


Thus, when TLSA records are used with opportunistic protocols where 
PKIX-TA(0) and PKIX-EE(1) do not apply, the recommended protocol 
design is for servers to not publish such TLSA records, and for 
opportunistic TLS clients to use them to only enforce the use of 
(albeit unauthenticated) TLS but otherwise treat them as unusable. 

Of course, when PKIX-TA(0) and PKIX-EE(1) are supported by the 
application protocol, clients MUST implement these certificate usages 
as described in [RFC6698] and this document. 
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